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INTELLIGENT BLUETOOTH INQUIRY PROCEDURE 
Background Of the Invention 

The present invention generally relates to network configuration. More 
particularly, the present invention relates to providing network nodes with 
information related to other nodes which the network nodes can use when forming a 
network. 

Conventional networking protocols are based on the characteristics and/or 
features of fixed networks. In fixed networks, the network configuration typically 
does not change. Although nodes can be added and removed in fixed networks, 
the route traveled by data packets between two nodes typically does not change. 
The disadvantage is that fixed networks cannot be easily reconfigured to account 
for increases in data traffic, also called system loading. Accordingly, when 
system loading increases for one node, the surrounding nodes are likely to 
experience increased delays in the transmission and reception of data. 

In contrast to fixed networks, ad-hoc networks are dynamic. An ad-hoc 
network is formed when a number of nodes decide to join together to form a 
network. Since nodes in ad-hoc networks operate as both hosts and routers, ad- 
hoc networks do not require the infrastructure required by fixed networks. 
Accordingly, ad-hoc networking protocols are based upon the assumption that 
nodes may not always be located at the same physical location. 

Bluetooth is an exemplary ad-hoc networking technology. Bluetooth is an 
open specification for wireless communication of both voice and data. It is based 
on a short-range, universal radio link, and it provides a mechanism to form small 
ad-hoc groupings of connected devices, without a fixed network infrastructure, 
including such devices as printers, PDAs, desktop computers, FAX machines, 
keyboards, joysticks, telephones or virtually any digital device. Bluetooth 
operates in the unlicenced 2.4 GHz Industrial-Scientific-Medical (ISM) band. 

Figure 1 illustrates a Bluetooth piconet. A piconet is a collection of digital 
devices, such as any of those mentioned above, connected using Bluetooth 
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technology in an, ad-hoc fashion. A piconet is initially formed with two connected 
devices, herein referred to as Bluetooth devices. A piconet can include up to eight 
Bluetooth devices. In each piconet, for example piconet 100, there exists one 
master Bluetooth unit and one or more slave Bluetooth units. In Figure 1 
Bluetooth unit 101 is a master unit and unit 102 is a Bluetooth slave unit. 

Figure 2 illustrates a larger piconet, including a master and several slaves. 
According to Bluetooth technology a slave unit can only communicate directly 
with a master unit. Figure 2 illustrates a piconet with a master unit 201 and a 
plurality of slave units 202-208 arranged in a star network topology. If slave unit 
202 wishes to communicate with slave unit 206, slave unit 202 would have to 
transmit the information it wished to communicate to master unit 201. Master unit 
201 would then transmit the information to slave unit 206. 

Figure 3 illustrates an exemplary scatternet 300. A scatternet is formed by 
multiple independent and unsynchronized piconets. In Figure 3, piconet 1 
includes the master node 303 and slave nodes 301, 302 and 304; piconet 4 
includes the master node 305 and slave nodes 304, 306, 307 and 308; and piconet 
5 includes the master node 309 and slave nodes 308 and 310. To implement a 
scatternet it is necessary to use nodes which are members of more than one 
piconet. Such nodes are herein referred to as forwarding nodes. If, for example, 
node 301 wishes to communicate with node 310, then nodes 304 and 308 might 
act as forwarding nodes by forwarding the information between the two piconets 
and in particular between nodes 301 and 310. For example, node 301 transfers 
the information to the master node of piconet 1 node 303. Master node 303 
transmits the information to forwarding node 304. Forwarding node 304 then 
forwards the information to master node 305, which in turn, transmits the 
information to forwarding node 308. Forwarding node 308 forwards the 
information to master node 309 which transmits the information to the destination 
node 310. 
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A Bluetooth unit can simultaneously be a slave member of multiple piconets, 
but only master in one piconet. Additionally, a Bluetooth unit that acts as master in 
one piconet can participate in other piconets as a slave. A Bluetooth unit can only 
transmit and receive data in one piconet at a time, so participation in multiple 
piconets has to be on a time division multiplex basis. 

Each Bluetooth unit has a globally unique 48 bit IEEE 802 address. This 
address, called the Bluetooth Device Address (BD ADDR) is assigned when the 
Bluetooth unit is manufactured and it is never changed. In addition, the master of 
a piconet assigns a local active member address (AM_ADDR) to each active 
member of the piconet. The AM ADDR, which is only three bits long, is 
dynamically assigned and de-assigned and is unique only within a single piconet. 
The master uses the AM_ADDR when polling a slave in a piconet. However, 
when the slave, triggered by a packet from the master addressed with the slave's 
AM_ADDR, transmits a packet to the master, it includes its own AMADDR (not 
the master's) in the packet header. 

Figure 4 illustrates a Bluetooth packet. The conventional Bluetooth packet 
consists of access code 410, header 420 and payload 430. The header 420 
contains tire AM ADDR followed by some control parameters, e.g., a bit 
indicating acknowledgment or retransmission request of the previous packet, when 
applicable, and a header error check (HEC). The access code in the packet can be 
of three different types including a channel access code (CAC), a device access 
code (DAC) or an inquiry access code (IAC). 

The channel access code identifies a channel that is used in a particular 
piconet, i.e., in essence the channel access code identifies the piconet. 
Accordingly, all packets exchanged within a piconet carry the same channel access 
code. The channel access code is derived from the BD ADDR of the master unit 
of the piconet. The device access code is derived from a BD ADDR of a 
particular Bluetooth unit. The device access code is used for special signaling 
procedures, e.g., the PAGE procedure, as will be described below. There are two 
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types of inquiry access codes, the general inquiry access code (GIAC) and the 
dedicated inquiry access code (DIAC). The general inquiry access code (GIAC), is 
sent to discover any Bluetooth unit in the neighborhood. The dedicated inquiry 
access code (DIAC), is sent to discover only certain types of Bluetooth units. Each 
individual dedicated inquiry access codes is unique to a different type of Bluetooth 
unit. Both the general inquiry access code and the dedicated inquiry access code 
are used in the INQUIRY procedure. 

Since ad-hoc networks are dynamic, ad-hoc networking technology 
typically has a neighbor discovery feature. The neighbor discovery feature allows 
one Bluetooth unit to find any other Bluetooth unit which the first Bluetooth unit 
can communicate with and consequently form an ad-hoc network with. A 
neighbor discovery procedure in Bluetooth is known as the INQUIRY procedure. 
Once a Bluetooth unit knows of neighboring Bluetooth units, a Bluetooth unit can 
connect to the neighboring Bluetooth unit using the PAGE procedure. 

Figure 5 illustrates the signaling performed between two Bluetooth units for 
neighbor discovery and connection establishment. Note that in Figure 5, there are 
two headings "Message." These are meant to indicate the relative sequencing of 
transmissions. A Bluetooth unit, such as Bluetooth unit 1 wishing to discover 
neighboring Bluetooth units broadcasts an INQUIRY message. A Bluetooth unit 
issuing an INQUIRY message is referred to as an inquiring Bluetooth unit (IBTU). 
The Bluetooth unit then waits and listens for INQUIRY RESPONSE messages. An 
INQUIRY message consists of only an inquiry access code, i.e. either a GIAC or 
DIAC. The INQUIRY message will be sent repeatedly according to well specified 
timing and frequency sequences. 

When a neighboring Bluetooth unit, such as Bluetooth unit 2, receives an 
INQUIRY message, Bluetooth unit 2 responds with an INQUIRY RESPONSE 
message. The neighboring Bluetooth unit that responds to the inquiring Bluetooth 
unit is referred to as a responding Bluetooth unit (RBTU). The INQUIRY 
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RESPONSE message is a frequency hop synchronization (FHS) packet. Messages 1 
and 2 constitute the neighbor discovery procedure, or, INQUIRY procedure. 

Figure 6 illustrates a frequency hop synchronization packet. All fields in the 
FHS packet, except the AM_ADDR field (and the undefined field) indicate 
properties or parameters of the Bluetooth unit that sends the FHS packet. The FHS 
packet includes fields for parity bits, lower address part (LAP), scan repetition (SR), 
scan period (SP), upper address part (UAP), non-significant address part (NAP), 
Class of Device, AMADDR, internal value of the sending unit's clock (CLK), and 
Page Scan Mode. The LAP, UAP and NAP together comprise the BDADDR of 
the sending unit. 

The "Class of Device" field indicates the class of device of the responding 
Bluetooth unit. For example, a class of device might be a fax machine, or phone or 
printer, or refrigerator. The CLK field contains the current value of the responding 
Bluetooth unit's internal clock. The SR, SP and Page Scan Mode fields are control 
parameters used during the PAGE procedure. The AM_ADDR field can be used to 
assign an AMADDR to a Bluetooth unit which is becoming a slave in a piconet 
(i.e. the AM_ADDR is only used when the FHS packet is used in the PAGE 
procedure) and the undefined field is reserved for future use. 

Referring again to Figure 5, when a Bluetooth unit desires to establish a 
connection with a neighboring Bluetooth unit, the Bluetooth unit sends a PAGE 
message. Messages 3 through 6 constitute the connection procedure, or PAGE 
procedure. A PAGE message (message 3) consists of the Device Access Code 
(DAC), derived from the BD_ADDR of the paged Bluetooth unit. A Bluetooth unit, 
e.g., Bluetooth unit 2, receiving a PAGE message including its own DAC responds 
with an identical packet, i.e., a packet including only the DAC (message 4) of the 
paged Bluetooth unit (Bluetooth unit 2). The paging Bluetooth unit, i.e., Bluetooth 
unit 1, then replies with an FHS packet (message 5) , including the BD ADDR of 
the paging Bluetooth unit (Bluetooth unit 1), the current value of the internal clock 
of the paging Bluetooth unit (Bluetooth unit 1), the AM . ADDR assigned to the 
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paged Bluetooth unit (Bluetooth unit 2) and other parameters. The paged Bluetooth 
unit (Bluetooth unit 2) then responds with its DAC (message 6) thereby establishing 
a connection between the two Bluetooth units. If the paging Bluetooth unit already 
was the master of a piconet, the paged Bluetooth unit has now joined this piconet as 
a new slave unit. Otherwise, the two Bluetooth units have just formed a new piconet 
with the paging Bluetooth unit as the master unit. 

Even though existing Bluetooth specifications describe the mechanisms that 
can be used to create piconets and form scatternets, the criteria to create a specific 
scatternet is not specified. The INQUIRY and PAGE procedures are well specified, 
but no rules or guidelines exist as to how to use them. For example, when neighbors 
are discovered there is no way to know who to connect to in order to form an 
appropriate piconet. Hence, piconets will more or less form at random, often 
resulting in far from optimal piconet and scatternet structures. 

The provision of information about available services and device types 
would facilitate the piconet and scatternet forming procedures. Further, since setting 
up connections with a plurality of nodes in order to retrieve this type of information 
is a very time consuming task, i.e., requiring performing an INQUIRY and PAGE 
procedure with each of the plurality of nodes, the provision of information about 
available services and devices types prior to actual connection establishment 
improves a node's ability to make informed decisions as to which nodes to connect 
to. 
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Summary of the Invention 

In accordance with exemplary embodiments of the present invention, 
methods and apparatus are provided for informing network nodes of services 
available and/or device types present in a network prior to the establishment of a 
connection between a node and the network. More specifically, in response to a 
message which is used to discover neighboring nodes, neighboring nodes reply with 
a message which indicates services and/or device types present in the neighboring 
node's network. 

An exemplary embodiment of the invention comprises a method for 
selectively establishing a communication link between an inquiring Bluetooth unit 
and one or more of a plurality of neighboring Bluetooth units. The method begins 
by the inquiring Bluetooth unit transmitting an INQUIRY message, which contains 
an inquiry access code. The inquiry access code represents a request by the 
inquiring Bluetooth unit to determine if any service or device is accessible through 
neighboring Bluetooth units. The neighboring Bluetooth unit(s), if they have 
received the inquiring Bluetooth units INQUIRY message transmits an INQUIRY 
RESPONSE message to the inquiring Bluetooth unit, which contains the accessible 
device or service information requested, and other information useful in making a 
connection between the neighboring Bluetooth unit(s) and the inquiring Bluetooth 
unit. A neighboring Bluetooth unit that responds in tins manner is known as a 
responding Bluetooth unit. If the responding Bluetooth unit is connected (either 
through its own, or through its own and other piconets) to a service or device of 
interest to the inquiring Bluetooth unit (or is itself such a device or offering such a 
service), the inquiring Bluetooth unit may choose to connect with that responding 
Bluetooth unit, or another or several responding Bluetooth units, each of which has 
access to the desired service or device type. The inquiring Bluetooth unit can then 
use information acquired from the INQUIRY message to generate a page message to 
the responding Bluetooth unit. Next, the responding Bluetooth unit responds by 
sending a message including the DAC of the responding Bluetooth unit to the 
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inquiring Bluetooth unit. Upon reception of the response message, the inquiring 
Bluetooth unit transmits a FHS packet which contains selective connection data to 
connect to the responding Bluetooth unit. The responding Bluetooth unit will then 
transmit a DAC message to the inquiring Bluetooth unit, forming a connection. 

In accordance with one embodiment of the present invention, herein is 
presented a method for providing connection information in an ad-hoc network 
comprising the steps of broadcasting an inquiry message, from an inquiring node, to 
neighboring nodes, the inquiry message requesting connection information about 
accessible nodes. The inquiring node receiving a response from a neighboring node, 
the response containing connection information about the responding node and 
nodes which are accessible by the neighbor nodes. Lastly, determining whether to 
establish a network with the responding neighbor nodes using the connection 
information in the response. 

Brief Description of the Several Drawings 

The objects and advantages of the invention will be understood by reading 
the following detailed description in conjunction with the drawings in which: 
FIG. 1 illustrates a Bluetooth piconet; 

FIG. 2 illustrates a larger piconet, including a master and several slaves; 
FIG. 3 illustrates an exemplary scatternet; 
FIG. 4 illustrates an INQUIRY message packet; 

FIG. 5 illustrates the signaling performed between two Bluetooth units for 
neighbor discovery and connection establishment; 

FIG. 6 illustrates an INQUIRY RESPONSE message packet; 

FIG's. 7 and FIG. 10 illustrate signaling between two nodes for establishing a 
selective connection in accordance with a first embodiment of the invention; 

FIG. 8 illustrates the bit allocation of the redefined fields of an INQUIRY 
RESPONSE message packet; 
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FIG. 9 illustrates a bit map example of the available bits from the redefined 
fields in an INQUIRY RESPONSE message packet; 

FIG. 1 1 illustrates a list example of the available bits from the redefined 
fields in an INQUIRY RESPONSE message packet; 

FIG's 12, 14, 15, 16, 18 and 19, illustrate signaling between two nodes for 
establishing a selective connection in accordance with a second embodiment of the 
invention; 

FIG. 13 illustrates an INQUIRY message packet, modified with a first 
inquiry access code; 

FIG. 17 illustrates an extended INQUIRY RESPONSE message, showing a 
bit allocation for redefined fields in the extension part of the extended INQUIRY 
RESPONSE message; 

FIG. 20 illustrates an extended INQUIRY RESPONSE message, showing a 
bit allocation for redefined fields in the first (regular) and second (extension) part of 
the extended INQUIRY RESPONSE message; 

FIG's 21, 23, 24, 25, 26 and 27 illustrate signaling between two nodes for 
establishing a selective connection in accordance with a third embodiment of the 
invention; 

FIG. 22 illustrates an INQUIRY message packet, modified with a second 
inquiry access code; 

FIG's 28, 30, 31, 32, 33 and 34 illustrate signaling between two nodes for 
establishing a selective connection in accordance with a fourth embodiment of the 
invention; 

FIG. 29 illustrates an INQUIRY message packet, modified with a third 
inquiry access code; 

FIG's 35. 37, 38, 39, 40 and 41 illustrate signaling between two nodes for 
establishing a selective connection in accordance with a fifth embodiment of the 
invention; 
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FIG. 36 illustrates an INQUIRY message packet, modified with a fourth 
inquiry access code; 

FIG. 42 illustrates several piconets, showing the number of hops from an 
inquiring Bluetooth unit, to a device offering a certain type of service or a device of 
a certain type; 

FIG. 43 illustrates an example of embedding hop count information in an 
INQUIRY RESPONSE message, with redefined fields; 

FIG. 44 illustrates an example of embedding hop count information in an 
extended INQUIRY RESPONSE message; 

FIG. 45 illustrates an example of embedding hop. count information in a first 
and extended INQUIRY RESPONSE message; 

FIG. 46 illustrate signaling between two nodes for establishing a selective 
connection in accordance with a sixth embodiment of the invention; 

FIG. 47 illustrates an INQUIRY message packet, modified with a fifth 
inquiry access code; 

FIG. 48 illustrates a first example of embedding hop count information in an 
INQUIRY RESPONSE message; 

FIG. 49 illustrates a second example of embedding hop count information in 
an extended INQUIRY RESPONSE message; 

FIG. 50 illustrates, as Table 3, the different types of inquiry access codes, 
their definitions, and examples of each; 

FIG. 5 1 illustrates a block diagram of an arrangement in which the present 
invention can be carried out; and 

FIG. 52 illustrates an exemplary set of apparatuses within which the 
arrangement of FIG. 51 can be implemented. 
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Detailed Description of the Invention 

The present invention is directed to ad-hoc networks. More particularly, the 
present invention is directed to obtaining information about available devices and/or 
services in ad-hoc networks. 

In the following it is described that a node sends a request for connection 
information regarding services or device types. It is recognized that in the ad-hoc 
networking art in general, and Bluetooth in particular, that a node is associated 
with a physical object: a fax machine, computer; scanner, car radio, etc. These 
physical objects are herein referred to as devices. The present invention provides 
information regarding devices to inquiring nodes. Further in accordance with the 
present invention, the inquiring BLUETOOTH unit can request (or be given) 
information about "services" as well. As a service is not a physical object, it is 
technically not a "node." But, in order to access a service, the inquiring 
BLUETOOTH unit must access a node that either provides the service, or is a 
node connected to another node that can provide the service (and so on). 
Therefore, although not technically accurate to equate a "node" and "service," for 
the purposes of the present invention, it is to be understood that a request for 
connection information regarding services, is the same as requesting information 
regarding services provided by nodes - because only through a node can the 
service be accessed. 

Figure 7 illustrates signaling between two nodes for establishing a selective 
connection in accordance with a first embodiment of the invention. 

Conventionally, when an inquiring Bluetooth unit broadcasts the INQUIRY 
message, it cannot indicate what services or device types it is interested in 
connecting with. As illustrated in figure 7, the inquiring Bluetooth unit broadcasts 
an INQUIRY message (1) to all neighboring nodes. The numbers in parentheses 
indicate the order in which a particular message is transmitted; that is, the relative 
timing of message transmissions that the inquiring and responding Bluetooth units 
broadcast or transmit. 
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No "master" or slave" has been established between the nodes because no 
firm connection has been created between the nodes. However, the transmission 
protocol is setting up the inquiring Bluetooth unit to be the master, and the 
responding Bluetooth unit to be the slave. 

A neighboring Bluetooth unit which receives an INQUIRY message and 
responds by sending an INQUIRY RESPONSE message is referred to as a 
responding Bluetooth unit (RBTU). In accordance with a first embodiment of the 
present invention, a responding Bluetooth unit uses the Class of Device field, the 
AM_ADDR field, the Undefined field, and the NAP field in the INQUIRY 
RESPONSE message to provide information about accessible services or device 
types. It should be understood that redefining any combination of a subset of these 
three fields would not alter the principles of this embodiment, just reduce the 
number of redefined bits. However, in this particular embodiment, the Class of 
Device field has to be one of the redefined fields, which will be understood by 
further description of the embodiment. 

Figure 8 illustrates the bit allocation of the redefined fields of an INQUIRY 
RESPONSE message packet. In figure 8, the Undefined field (shown by (1)), the 
NAP field (2), the Class of Device field (3), the AM_ADDR field (4) have been 
redefined to convey connection information about available services or device 
types. "Redefine" means the bits allocated for the purpose indicated by the field 
name (AM_ADDR, for example), have now been made available to convey 
connection information. Instead of conveying the AM_ADDR data of the 
responding Bluetooth unit, the bits convey connection information. 

Within conventional INQUIRY RESPONSE messages, the Class of Device 
field is broken into two sections. The first section comprises the first 2 bits, and the 
latter section contains the latter 22 bits. The first section is designed to indicate 
which one of four independent formats the remainder of the Class of Device field 
follows. Presently, only one of the four formats is defined and it indicates which 
class the responding device belongs to. Within the presently specified format code, 
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the remaining 22 bits are divided among three subclasses: service classes 
(networking, capturing, audio, telephony, etc.), major device class (computer, phone 
LAN, access point, peripheral, etc.) and minor service class (detailed subclasses of 
major device class, e.g. desktop workstation, laptop, palm sized PC/PDA, etc., if the 
major subclass is "computer"). 

Although it is preferred to use one of the undefined codes (in the first two 
bits of the Class of Device field) to indicate the INQUIRY RESPONSE message 
contains connection information about services or device types, the currently defined 
code could be used as well. The remaining 22 bits of the Class of Device field will 
then be used to convey information about accessible services or device types. 

The AM_ADDR field has three bits that can be used to convey information 
about accessible services or device types, since the AM_ADDR field in an FHS 
packet is only used in the PAGE procedure and not in an INQUIRY RESPONSE 
message. The two Undefined bits can also be used to convey information about 
accessible services or device types. In addition, the NAP field (16 bits) can be used 
also, bringing the total number of available bits to convey information about 
accessible services or device types to 43. 

In accordance with the present invention, the first two bits of the Class of 
Device field are used by the responding Bluetooth unit to inform the inquiring 
Bluetooth unit that the responding Bluetooth unit is returning an INQUIRY 
RESPONSE message with redefined fields which indicates what services or device 
types the responding Bluetooth unit is connected to or represents itself. See Table 1, 
which illustrates the bit allocation for each field. 
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Table 1 



Field Name 


Bit Allocation 


Class of Device 




-Format 


(2) 


-Data 


22 


AMADDR 


3 


Undefined Field 


2 


NAP 


16 


Total: 


43 



In accordance with the present invention, the 43 bits of the redefined fields 
will contain information about accessible services or device types using a bit map. 
In Table 1, the total shows 43, because the 2 bits of the Class of Device format bits 
are not used to convey connection information. Figure 9 illustrates an exemplary bit 
map using the available bits from the redefined fields in an INQUIRY RESPONSE 
message packet. 

Each bit of the bit map represents whether a service or device type is 
accessible (e.g. a particular bit being set to one) or not accessible (e.g, a particular 
bit being set to zero) by the responding Bluetooth unit. For example, bit 22 can 
represent Network Access Point services; bit 30 can represent Application services. 
These are examples only, and as such, are not meant to limit the invention. . The bits 
are numbered from right to left. 

In figure 9, there are two columns; the left column is entitled "Available 
Bits" and the right column is entitled "Definition." The "Available Bits" column 
shows the 45 available bits grouped together, in one continuous string. In any 
particular row, the two left-most bits represent the bit contribution from the 
Undefined field. The next 16 bits are those from the NAP field. The next 24 bits 
are those from the Class of Device field. The last three bits are those from the 
AM ADDR field. 
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It will be recognized that to be able to cope with future growth of the number 
of services or device types an available bit should be allocated to represent the 
general service class "other sendees" in the case of reporting about available 
services. Similarly, when reporting about available device types, an available bit 
should be allocated to represent the general device type class "other device types." 
In either situation, the same available bit might be allocated for this use, or it could 
be different available bits for services and device types. 

In accordance with the present invention, the first two bits of the Class of 
Device field (bits 4 and 5) are reserved to indicate an INQUIRY RESPONSE 
message that contains connection information. These two bits are shown in bold in 
figure 9. This leaves 43 bits available to convey connection information. 

In figure 9, the first line shows a printer service, fax service, scanner service, 
network access point service and application service, as being described in the first 
bit map. An application service is the service of allowing a customer to pay to use 
an application program residing in the application service provider's computer. 
Network access point service is the service of allowing a Bluetooth unit to access 
some network at some point in the network. Note that a total of five bits have been 
set to "1." A "1" indicates the service or device type is present, i.e. connection 
information is known about it. In the second row, the bit for the network access 
point service is underlined, and in the third line, the bit for the application service is 
underlined. 

Because a bit map allows the responding Bluetooth unit to inform the 
inquiring Bluetooth unit about the accessibility or non-accessibility of many 
different services or device types in a dense format (only one bit per sendee or 
device type), it is efficient. .However, because each service or device type is 
allocated one bit, the bit map is limited to the number of available bits. In this case, 
information concerning a maximum of 43 different device types or services can be 
relayed to the inquiring Bluetooth unit. 

The accessible services or device types are those services or device types that 
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are accessible to the responding Bluetooth unit. Typically, this information is 
known to the responding Bluetooth unit well before an inquiring Bluetooth unit 
INQUIRY message is broadcast. Information about accessible services and device 
types could be distributed in a scatternet using one of the existing protocols for 
publishing, discovery and location of services, such as the Service Discovery 
Protocol (SDP) of Bluetooth, the Service Location Protocol (SLP, RFC2608), the 
Simple Service Discovery Protocol (SSDP) of UPnP (Universal Plug and Play), or 
the Extended Sendee Discovery Protocol which is an extension of SDP based on 
UPnP. The accessible device types could be derived from the service information or 
distributed via similar means. To reduce the load in the network these mechanisms 
can use the concept of proxies or agents which hold service information on behalf of 
the service publishers. Other Bluetooth units can then request this information from 
an agent or proxy or an agent or proxy can transfer information triggered by some 
specified event. 

Referring again to figure 7, the INQUIRY RESPONSE message (2) occurs 
after the INQUIRY message. After the inquiring Bluetooth unit receives the 
INQUIRY RESPONSE message, from neighboring Bluetooth Units, the inquiring 
Bluetooth unit decides which, if any, of the responding Bluetooth units to attempt to 
connect to (assuming that any or more than one has responded). Assuming that the 
responding Bluetooth unit indicates that the desired device type or service is 
accessible (implying that either the responding Bluetooth unit itself or another node 
reachable through the same ad-hoc network provides the desired service or is of the 
desired device type), the inquiring Bluetooth unit responds to the INQUIRY 
RESPONSE message by transmitting a PAGE message (3) to the specific 
responding Bluetooth unit. The responding Bluetooth unit that receives a PAGE 
message directed to it responds by transmitting an identical message (i.e. including 
its own DAC) (4) to the inquiring Bluetooth unit. The inquiring Bluetooth unit 
receives that response message from the responding Bluetooth unit and transmits a 
message consisting of a FHS packet (5) to the responding Bluetooth unit. The 
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responding Bluetooth unit, upon reception of the FHS packet from the inquiring 
Bluetooth unit responds by transmitting another message consisting of its own DAC, 
(6), which, when received by the inquiring Bluetooth unit, completes the connection 
forming process, and the two Bluetooth units are formally connected. 

For purposes of illustration only, figure 7 shows the inquiring Bluetooth unit 
as attempting to connect to a single responding Bluetooth unit. This in no way 
limits the invention, as the number of responding Bluetooth units an inquiring 
Bluetooth unit can attempt to connect to is theoretically unlimited. 

Figure 10 illustrates signaling between two nodes for establishing a selective 
connection in accordance with a first embodiment of the invention. 

The embodiment of the invention described in reference to figure 10 is 
similar to that as described in figure 7, except that the information about accessible 
services or device types is encoded in a list format, instead of a bit map. The bits 
will list predefined identities of accessible services or device types. Such 
standardized service identities already exist to be used in conjunction with the 
service information distribution protocols mentioned above. 

Figure 1 1 illustrates a list example of the available bits from the redefined 
fields in an INQUIRY RESPONSE message packet. In the list, a particular number 
of consecutive bits are used to list accessible services or device types. In figure 11, 
eight bits are used, by way of example only. Again, the first two bits of the Class of 
Device field (shown in bold) have been set to "1" to indicate that the responding 
Bluetooth unit has connection information for the inquiring Bluetooth unit about 
certain services or device types, i.e. to indicate the format code of the INQUIRY 
RESPONSE message. 

In the first line, the first and second nibble (numbered from left to right, for 
illustration purposes only) have been underlined to represent the list identity (0010 
1001) for printer services. In nibbles three and four, the list identity of the fax 
service (1000 0100) is shown. Following that, the list identity of the application 
service (001 1 0000), scanner service (001 1 0001) and finally, network access point 
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services (01 10 1001) are shown. The second row shows the identity of the network 
access point service (01 10 1001) alone. 

In figure 11, by way of example only, the second row shows the service 
identity of a network access point service placed in nibbles 9 and 10. Note that this 
is the first available identity field space; if there is only one service identity to 
report, it will be placed here. The responding Bluetooth unit will place the service 
or device type identity in the most convenient position, not in any specific one. If 
there were two service identities, they would be placed in nibbles 9 and 10. and then 
nibbles 7 and 8, respectively. This is the situation shown in figure 11, row three. 

The examples just shown are merely an illustration of how a list might be 
constructed in this embodiment. Although figure 1 1 illustrates 8 bits defining the 
identity of the service or device type it will be recognized that other bit field sizes 
can be used to define identities. The number of services or device type identities 
that can be transmitted at once is limited to the number of available bits divided by 
the number of bits used to define an identity. In this example, 43 divided by 8, 
yields 5 identities for each INQUIRY RESPONSE message, plus 3 extra bits. 

There are only 2 8 different identities available to be defined because each 
identity uses 8 bits. This yields 256 identities. 254 would be used, because the 
identity of 1111 1111 would be used to indicate "other services," or other "device 
types." The all-zero identity, or 0000 0000, can not be used because the superfluous 
bits after the last item should be set to zero to distinguish them from list items (i.e. 
service or device type identities). 

If the size of the identity is defined to be 8 bits, there will be 3 bits leftover. 
The unused bits can define a flag to indicate that more sendees or device types are 
available or known about by the responding Bluetooth unit. Additionally, services 
will only be reported once; if the responding Bluetooth unit knows of, or is 
connected to 2 or more printing services, for example, it will report knowledge of 
being connected to one only. 
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Note an important difference in using a bit map versus lists in the first 
embodiment of the invention: The range of possible services or device types to 
report about is much larger if a list format is used (254 different services or device 
types in this example) than if a bit map is used (42 different services or device types 
in this example, plus the bit for "other services" or "other device types"). On the 
other hand the advantage of the dense bit map format is that it can report about more 
services or device types in the same INQUIRY RESPONSE message (42 in this 
example) than the list format (only 5 in this example). 

Figure 12 illustrates signaling between two nodes for establishing a selective 
connection in accordance with a second embodiment of the invention. 

hi accordance with the second embodiment of the present invention, the 
INQUIRY message contains information as to what connection information the 
inquiring Bluetooth unit is seeking. This indication is accomplished by utilizing a 
new access code placed in the INQUIRY message. The first inquiry access code is 
referred to as an accessible services general inquiry access code (AS-GIAC). Figure 
13 illustrates an INQUIRY message packet, modified with a first inquiry access 
code. Use of the first inquiry access code signifies that the inquiring Bluetooth unit 
is interested in the services that are accessible via the neighboring Bluetooth units, 
including service provided by the neighboring Bluetooth units themselves. 

In accordance with the present invention, upon receipt of an INQUIRY 
message containing an AS-GIAC, the neighboring Bluetooth units will respond 
regardless of whether they are connected to any services or device types or not, and 
regardless of the types of services or devices, or how many they are connected to. 

As with the first embodiment of the invention, there are several ways in 
which to transfer the useful connection information from the responding Bluetooth 
unit to the inquiring Bluetooth unit in the second embodiment. The first is by 
redefining the fields in the INQUIRY RESPONSE message, as was discussed 
previously. The same fields can be redefined, in the same manner, with the 
exception of the Class of Device field. Here, it is not necessary to use the first two 
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bits to indicate the special format: The reason for this is because use of the AS- 
GIAC, in the INQUIRY message, indicates that the returned INQUIRY RESPONSE 
is going to be providing the useful connection information. Therefore, instead of 
only 43 available bits, there will be 45 available bits. See Table 2. In figure 9, the 
INQUIRY RESPONSE IS shown in the second (2) message. 



Table 2 



Field Name 


Bit Allocation 


Class of Device 






-Format 


2 




-Data 


22 




AMADDR 


3 




Undefined Field 


2 




NAP 


16 




Total: 


45 



As described above in connection with figures 8 and 8A connection 
information can be conveyed in the INQUIRY RESPONSE message using either a 
list or a bit map. 

In figure 12, a bit map is used to convey connection information from the 
responding Bluetooth unit to the inquiring Bluetooth unit, about available services, 
in redefined fields of an INQUIRY RESPONSE message. 

Figure 14 illustrates signaling between two nodes for establishing a selective 
connection in accordance with a second embodiment of the invention. 

In figure 14, the first inquiry access code in the INQUIRY message is an AS- 
GIAC, and a list is used to convey connection information from the responding 
Bluetooth unit to the inquiring Bluetooth unit, about available services, in redefined 
fields of an INQUIRY RESPONSE message. 
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The method of using a list to convey connection information with an AS- 
GIAC, according to the second embodiment of the invention, is the same as has been 
discussed with the first embodiment. However, instead of there being 43 bits 
available to convey connection information in the INQUIRY RESPONSE message, 
there will now be 45 bits available. 

Figures 15 and 16 illustrate signaling between two nodes for establishing a 
selective comiection in accordance with a second embodiment of the invention. 

The second way to convey useful connection information to the inquiring 
Bluetooth unit from the responding Bluetooth unit, in the second embodiment of the 
invention, is to use an extended INQUIRY RESPONSE message. The regular 
INQUIRY RESPONSE message is just one time slot long. An extended INQUIRY 
RESPONSE message would preferably be an integer number of time slots longer, 
e.g. one time slot longer, making the extended INQUIRY RESPONSE twice as long 
as a regular one. In the first time slot, i.e. the first part of the extended INQUIRY 
RESPONSE message, the fields of the regular INQUIRY RESPONSE message 
would be included, while the second time slot, i.e. the extension part of the extended 
INQUIRY RESPONSE message, could be used for connection information. Using 
an extended INQUIRY RESPONSE message provides a great deal of available bits 
to provide useful connection information. 

In figure 15 a bit map is used to encode connection information in the 
extension part of the INQUIRY RESPONSE message. 

In figure 16 a list is used to encode connection information in the extension 
part of the INQUIRY RESPONSE message. 

Figure 17 illustrates an extended INQUIRY RESPONSE message, showing 
the bit allocation for redefined fields in the extension part of the extended INQUIRY 
RESPONSE message. The entire extended portion of the INQUIRY RESPONSE 
message is available for encoding data, either as a bit map, or as a list. The previous 
discussion of bit usage with respect to figures 9 and 1 1 also pertain to this 
embodiment of the invention. The difference being the number of services or device 
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types the responding Bluetooth unit could report about, because of the increased 
number of available bits (144). 

Figures 18 and 19 illustrate signaling between two nodes for establishing a 
selective connection in accordance with a second embodiment of the invention. 

The third way to convey useful connection information to the inquiring 
Bluetooth unit from the responding Bluetooth unit, in the second embodiment of the 
invention, is to use an extended INQUIRY RESPONSE message along with 
redefining specific fields of the first (regular) part of the INQUIRY RESPONSE 
message. The same fields that were discussed in the first way to convey useful 
connection with an AS-GIAC will be redefined here. This third method, the 
combination of the first two, yields a tremendous amount of available bits to convey 
useful connection information. 

In figure 1 8 a bit map is used to encode connection information in the first 
(regular) and second (extension) part of the INQUIRY RESPONSE message. 

In figure 19 a list is used to encode connection information in the first 
(regular) and second (extension) part of the INQUIRY RESPONSE message. 

Figure 20 illustrates an extended INQUIRY RESPONSE message, showing a 
bit allocation for redefined fields in the first (regular) and second (extension) part of 
the extended INQUIRY RESPONSE message. Note that by redefining the fields of 
the first (regular) part of the INQUIRY RESPONSE message, a total of 189 bits are 
available for either a bit map, or a list. 

Referring again to figures 12, 14, 15, 16, 18 and 19, if the responding 
Bluetooth unit indicates that a desired service or device type is accessible (implying 
that either the responding Bluetoofii unit itself, or another node reachable through 
the same ad-hoc network, provides the desired service or is of the desired device 
type), the inquiring Bluetooth unit will initiate the PAGE procedure in a similar 
manner to that described in connection with figure 7. 
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Figures 21, 23, 24, 25, 26 and 27 illustrate signaling between two nodes for 
establishing a selective connection in accordance with a third embodiment of the 
invention. 

The third embodiment of the invention for providing useful connection 
information to an inquiring Bluetooth unit, is to change the INQUIRY message to 
include a second inquiry access code (IAC) that indicates that the inquiring 
Bluetooth unit desires to receive information about accessible device types. The 
second inquiry access code is known as accessible type of device general inquiry 
access code (ATD-GIAC). 

Figure 22 illustrates an INQUIRY message packet, modified with a second 
inquiry access code. 

Use of the second inquiry access code signifies that the inquiring Bluetooth 
unit is interested in the devices that are accessible via the neighboring Bluetoodi 
units (including the neighboring Bluetooth units themselves) and that all 
neighboring Bluetooth units that can "hear" the inquiring Bluetooth unit will 
respond. The neighboring Bluetooth units will respond regardless of whether they 
are connected to any services or device types or not, and regardless of the services or 
device types, or how many they are connected to. 

In figure 21 a bit map is used to encode connection information in the 
INQUIRY RESPONSE message field. 

Thus, connection information about device types can also be shared with an 
inquiring Bluetooth unit. All the same features described regarding redefining fields 
in an INQUIRY RESPONSE message, using an extended INQUIRY RESPONSE 
message, or a combination of the two, and then encoding the data through a bit map 
or lists, according to the second embodiment of the invention, are available for 
providing useful connection information about device types in the third embodiment 
of the invention. 

In figure 23 a list is used to encode connection information in the INQUIRY 
RESPONSE message field. 
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In figure 24 a bit map is used to encode connection information in an 
extension part of the INQUIRY RESPONSE message field. 

In figure 25 a list is used to encode connection information in the extension 
part of the INQUIRY RESPONSE message field. 

In figure 26 a bit map is used to encode connection information in the 
extension part of the INQUIRY RESPONSE message field and the certain redefined 
fields in the first (regular) part of the INQUIRY RESPONSE message fields. 

In figure 27 a list is used to encode connection information in the extension 
part of the extended INQUIRY RESPONSE message field and the certain redefined 
fields in the first (regular) part of the INQUIRY RESPONSE message. 

Referring again to figures 21, 23, 24, 25, 26 and 27, if the responding 
Bluetooth unit indicates that a desired service or device type is accessible (implying 
that either the responding Bluetooth unit itself or another node reachable through the 
same ad-hoc network, provides the desired service or is of the desired device type), 
the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to 
that described in connection with figure 7. 

Figures 28, 30, 31, 32, 33 and 34 illustrate signaling between two nodes for 
estabhshing a selective connection in accordance with a fourth embodiment of the 
invention. 

The fourth embodiment of the invention for providing useful connection 
information to an mquiring Bluetooth unit, is to change the INQUIRY message to 
include a third inquiry access code (IAC) that specifies which types of services (i.e. 
a subset of all types of services) the inquiring Bluetooth unit desires to receive 
information about. The third inquiry access code is known as a dedicated accessible 
services general inquiry access code (DAS-GIAC). There may be many DAS- 
GIAC's defined, each associated with a certain type of service (i.e. a certain subset 
of all types of services). 

Figure 29 illustrates an INQUIRY message packet, modified with a third 
inquiry access code. 
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Use of the third group of inquiry access codes signifies that the inquiring 
Bluetooth unit is interested in a smaller subset of services that are accessible via the 
responding Bluetooth unit and that all neighboring Bluetooth inquiring units that can 
"hear" the inquiring Bluetooth unit will respond. In this case, any neighboring 
Bluetooth unit that can hear the INQUIRY message will respond, but, will only pass 
along useful connection information regarding the type of specific service that is 
indicated by the DAS-GIAC. The DAS-GIAC will indicate a subset of the universal 
group of services that the inquiring Bluetooth unit is interested in. 

The use of DAS-GIAC in the INQUIRY message provides the ability to 
reduce the size of the bit-map (e.g. in order to make it always fit into an un-extended 
INQUIRY RESPONSE message) or the list. Each DAS-GIAC requests a certain 
category of accessible services (e.g. gateway services, printer services, or more 
general office services, etc.), which allows for greater efficiency in bit usage when 
encoding data about accessible services. 

In figure 28 a bit map is used to encode connection information in redefined 
fields of an INQUIRY RESPONSE message. 

In figure 30 a list is used to encode connection information in the certain 
redefined fields in the INQUIRY RESPONSE message. 

In figure 3 1 is a bit map is used to encode connection information in the 
extension part of the INQUIRY RESPONSE message. 

In figure 32 a list is used to encode connection information in the extension 
part of the INQUIRY RESPONSE message. 

In figure 33 a bit map is used to encode connection information in the 
extension part of the extended INQUIRY RESPONSE message and the certain 
redefined fields in the first (regular) part of the INQUIRY RESPONSE message. 

In figure 34 a list is used to encode connection information in the extension 
part of the extended INQUIRY RESPONSE message and the certain redefined fields 
in the first (regular) part of the INQUIRY RESPONSE message. 
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Thus, connection information about specific sei-vice types can be shared with 
an inquiring Bluetooth unit. All the same features described regarding redefining 
fields in an INQUIRY RESPONSE message, using an extended INQUIRY 
RESPONSE message, or a combination of the two, and then encoding the data 
through a bit map or a list, according to the second embodiment of the invention, are 
available for providing useful connection information about specific services in the 
fourth embodiment of the invention. 

Referring again to figures 28, 30, 31, 32, 33 and 34, if the responding 
Bluetooth unit indicates that a desired sendee or device type is accessible (implying 
that either the responding Bluetooth unit itself or another node reachable through the 
same ad-hoc network provides the desired service or is of the desired device type), 
the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to 
that described in connection with figure 7. 

Figures 35, 37, 38, 39, 40 and 41 illustrate signaling between two nodes for 
establishing a selective connection in accordance with a fifth embodiment of the 
invention. 

The fifth embodiment of the invention for providing useful connection 
information to an inquiring Bluetooth unit, is to change tire INQUIRY message to 
include a fourth inquiry access code (IAC) that specifies which types of devices (a 
subset of all device types) the inquiring Bluetooth unit desires to receive connection 
information about. The fourth inquiry access code is known as a dedicated 
accessible types of devices general inquiry access code (DATD-GIAC). There may 
be many DATD-GIAC's defined, each associated with a certain device type or 
category of device types. 

Figure 36 illustrates an INQUIRY message packet, modified with a fourth 
inquiry access code. 

Use of the fourth group of inquiry access codes signifies that the inquiring 
Bluetooth unit is interested in very specific device types that are accessible via the 
responding Bluetooth unit (including the responding unit itself) and that all 
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neighboring Bluetooth inquiring units that can "hear" the inquiring Bluetooth unit 
will respond. In this case, any neighboring Bluetooth unit that can hear the 
INQUIRY message will respond, but will only pass along useful connection 
information regarding the specific device types that are indicated by the DATD- 
GIAC. The DATD-GIAC will indicate a subset of the universal group of devices 
that the inquiring Bluetooth unit is interested in. 

The use of DATD-GIAC in the INQUIRY message provides the ability to 
reduce the size of the bit-map (e.g. in order to make it always fit into an un-extended 
INQUIRY RESPONSE message) or the list. Each DATD-GIAC requests a certain 
category of accessible device types. Examples are computers, computer peripherals, 
networking devices, network access points, telephones and fax machines, car 
accessories, hi-fi devices, household equipment, etc. which allows for greater 
efficiency in bit usage when encoding data about accessible device types. 

In figure 35 a bit map is used to encode connection information in redefined 
fields of an INQUIRY RESPONSE message. 

In figure 37 a list is used to encode connection information in redefined 
fields of an INQUIRY RESPONSE message. 

In figure 38 a bit map is used to encode connection information in the 
extension part of the INQUIRY RESPONSE message. 

Figure 39 a list is used to encode connection information in the extension 
part of the INQUIRY RESPONSE message. 

In figure 40 a bit map is used to encode connection information in the 
extension part of the extended INQUIRY RESPONSE message and redefined fields 
in the first (regular) part of the extended INQUIRY RESPONSE message. 

In figure 41a list is used to encode connection infonnation in the extension 
part of the extended INQUIRY RESPONSE message and redefined fields in the first 
(regular) part of the extended INQUIRY RESPONSE message. 

Thus, connection information about specific device types can be shared with 
an inquiring Bluetooth unit. All the same features described regarding redefining 
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fields in an INQUIRY RESPONSE message, using an extended INQUIRY 
RESPONSE message, or a combination of the two, and then encoding the data 
through a bit map or a list, according to the second embodiment of the invention, are 
available for providing useful connection information about specific device types in 
the fifth embodiment of the invention. 

Referring again to figures 35, 37, 38, 39, 40 and 41, if the responding 
Bluetooth unit indicates that a desired service or device type, is accessible (implying 
that either the responding Bluetooth unit itself or another node reachable through the 
same ad-hoc network provides the desired service or is of the desired device type), 
the inquiring Bluetooth unit will initiate the PAGE procedure in a similar manner to 
that described in connection with figure 7. 

In all of the first five embodiments of the invention, certain fields from an 
INQUIRY RESPONSE message have been redefined. It is to be understood that 
some or all of the fields may be used, and that the use of all four fields is for 
example purposes only, and is not meant not limit the spirit or scope of the 
invention. 

Furthermore, in all of the first five embodiments of the invention, another 
feature can be added that provides greater detail of the accessible services or device 
types, at the expense of some available bits. That is. the responding Bluetooth unit 
can provide hop count information to the inquiring Bluetooth unit, regarding each 
indicated accessible service or device type. Each service or device type indicated as 
accessible would have a hop count associated with it in the INQUIRY RESPONSE 
message. The hop count lets the inquiring Bluetooth unit know the number of hops - 
or connections - from the responding Bluetooth unit to the closet device offering a 
certain service or the closest device of a certain type. For instance, a hop count of 1 
means that the device offering the associated service or the device of the associated 
type is connected directly to the responding Bluetooth unit (but not to the inquiring 
Bluetooth unit). A hop count of 0, indicates that the responding Bluetooth unit is 
itself offering the service or is itself of the associated device type. Figure 42 
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illustrates several piconets, showing the number of hops from an inquiring Bluetooth 
unit, to a device offering a certain type of service or a device of a certain type, hi 
Figure 42, there are two piconets joined together. M(l) is the master of piconet 1, 
and M(2) is the master of piconet 2. In connection with M(l) are slaves S(l A), 
S(1B) and S(1C). Connected to M(2) are slaves S(2A), S(2B) and S(2C). Note that 
slave S(1C) and S(2A) are the same Bluetooth unit. In this scatternet, slave S(l A) 
has connection information about slave S(1B) and slave S(2B), that it can provide to 
the inquiring Bluetooth unit (TBTU). Path 1, the number of connections between 
S(l A) and S(1B), yields a hop count of 2. The hop count is determined by the 
connection between S(l A) and M(l), and the connection between M(l) and S(1B). 
Path 2, the number of connections between S(l A) and S(2B), yields a hop count of 
4. The hop count is determined by the connection between S(l A) and M(l), M(l) 
and S(1C/2A), S(1C/2A) and M(2), and M(2) and S(2B). 

A hop count can be represented with 1 or more bits. The number of bits used 
is a trade-off between efficient bit usage and the level of detail of the information. 
The number of bits used to represent hop count information determines the largest 
hop count that can be represented. For instance, if a hop count is represented by two 
bits, hop counts of 0-3 can be represented. If the real hop count is more than 3 hops, 
it would still be represented by a hop count of value of 3. So this would effectively 
mean "3 or more hops." The case when a hop count is represented by only 1 bit is 
particularly interesting. Partly because it does not use much space in the INQUIRY 
RESPONSE message. But more important is that such a simple hop count 
parameter can be set by a responding Bluetooth unit without having to retrieve the 
actual hop count in the network. It is not at all certain that the hop count to a 
service offering node or a node of a certain device type is possible to retrieve. This 
depends on the protocols that are supported in the network, e.g. the properties of the 
usual routing protocol. But the information needed to set a simple 1 bit hop count 
parameter is always available to the responding Bluetooth unit. This is because a I 
bit hop count parameter can only represent 2 different values: 0 hops or "1 or more 
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hops." And since 0 hops means "the responding Bluetooth unit itself and "1 or 
more hops" means "any other node in the scatternet," the responding Bluetooth unit 
will always know which of these two values to choose. 

Figure 43 illustrates an example embedding hop count information in an 
INQUIRY RESPONSE message with redefined fields. 

Here, the hop count information has been assigned to the NAP field, which 
has 16 bits. It could also have been assigned to the Undefined Field, the Class of 
Device Field, or the AM_ADDR field. In any case, the number of hop counts would 
be limited to the number of available bits in the particular data field. However, it is 
also possible to have assigned the hop count to any number of bits, anywhere in the 
available data fields. For example, the 3 bits of AM ADDR, and the first 2 bits of 
Class of Devices. It is for example purposes only that the hop count has been 
assigned to the NAP field, and not meant to limit or constrain the invention. 

When a bit map is used to encode accessible services or device types, each 
predefined service or device type in the bit map can have 2 bits instead of 1 assigned 
to it. One of the bits would indicate whether the particular service or device type is 
accessible through the responding Bluetooth unit or not; the other bit would 
represent the hop count of "0" or "1 or more hops" (provided that the first bit 
indicates that the particular service or device types is available. If the first bit 
indicates that the particular service or device types is not accessible, the hop count 
bit will have no meaning. 

In the case a list is used to encode accessible services or device types, each 
item will consist of a service (or device type) identity followed by a hop count 
parameter of one or more bits. 

Figure 44 illustrates an example of embedding hop count information in an 
extended INQUIRY RESPONSE message. 

Here, the hop count information has been given 16 bits in the extended 
INQUIRY RESPONSE message. The attribution of bits is for example purposes 
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only, and is not meant to limit the scope or spirit of the invention, in any manner 
whatsoever. 

Figure 45 illustrates an example of embedding hop count information in a 
first and extended INQUIRY RESPONSE message. 

Here, the responding Bluetooth unit is using a first and extended INQUIRY 
RESPONSE message to respond to the inquiring Bluetooth unit's query regarding 
services or device types. In this situation, the hop count information has been 
attributed to the first part of the INQUIRY RESPONSE message, and given 16 bits. 
Again, the number of bits is not materially limiting, nor is its location. The bits 
could also have been located in the extension part of the INQUIRY RESPONSE, in 
any position of the available 144 bits, and given any sufficient number to relay the 
hop count data. 

Figure 46 illustrate signaling between two nodes for establishing a selective 
connection in accordance with a sixth embodiment of the invention. 

The sixth embodiment of the invention for providing useful connection 
information to an inquiring Bluetooth unit, is to change the INQUIRY message to 
include a fifth inquiry access code (IAC) that specifies which services or device 
types the inquiring Bluetooth unit desires to communicate with. The fifth inquiry 
access code is known as an accessibility based dedicated inquiry access codes (A- 
DIAC). There may be many A-DIAC's defined, each associated with a certain type 
of service or device type or category of device types. 

Figure 47 illustrates an INQUIRY message packet, modified with a fifth 
inquiry access code. 

Use of the fifth group of inquiry access codes signifies that the inquiring 
Bluetooth unit is interested in very specific sendees or device types that are 
accessible via the responding Bluetooth unit and that only those neighboring 
Bluetooth inquiring units that can "hear" the inquiring Bluetooth unit and have 
access to the specific types of services or device types will respond, and 
subsequently are known as responding Bluetooth units. 
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Referring again to figure 46, if a Bluetooth unit responds to an INQUIRY 
message containing an A-DIAC, it thereby implicitly indicates that a desired service 
or device type is accessible, (implying that either the responding Bluetooth unit 
itself or another node reachable through the same ad-hoc network provides the 
desired service or is of the desired device type). Tire inquiring Bluetooth unit will 
then initiate the PAGE procedure in a similar manner to that described in 
connection with figure 7. It should be noted that in this embodiment the INQUIRY 
RESPONSE message does not have to be modified. 

An additional optional feature of the sixth embodiment of the invention (i.e. 
the A-DIAC embodiment) is that a responding Bluetooth unit could include the hop 
count to the closest device offering the type of service associated with the A-DIAC 
or the closest device of the type associated with the A-DIAC. In order to include the 
hop count information, the INQUIRY RESPONSE message has to be modified. 
This could be done by redefining a field in the regular INQUIRY RESPONSE 
message or extending the INQUIRY RESPONSE message. Any of at least four 
different fields could be redefined to carry the hop count information: tire Class of 
Device field, the AM_ADDR field, the Undefined field, or the NAP field. Only one 
has to be modified. If an extended INQUIRY RESPONSE message is used, the first 
part is used to carry the fields of a regular INQUIRY RESPONSE message, while 
the hop count information is placed in the extension part. 

As in the first five embodiments, the case when only a single bit is used to 
represent hop count is of particular interest. Partly because the space required in the 
INQUIRY RESPONSE message is small, but more importantly because the 
information of whether the hop count is "0" or "1 or more hops" is always available 
to the responding Bluetooth unit. In this sixth embodiment the size of the total hop 
count information may be very small, since the response to an A-DIAC INQUIRY 
RESPONSE message only has to include a single hop count parameter. If this hop 
count parameter is only 1 or 2 bits long, the undefined field in the INQUIRY 
RESPONSE message can be used to encode the hop count parameter and if the hop 
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count parameter is 1-3 bits long the AM_ADDR field can be used to encode the hop 
count parameter. Since both these fields are unused in the regular INQUIRY 
RESPONSE message, all the regular information of the INQUIRY RESPONSE 
message is left untouched in both these cases. 

Figure 48 illustrates a first example of embedding hop count information in 
an INQUIRY RESPONSE message. 

In Figure 48, the hop count information has been embedded in the Class of 
Device field. There are 24 bits available, but only 5 were allocated to encode the 
hop count information. With 5 bits allocated, the hop count information can 
represent 0 to 31 hops. As mentioned previously, the number of bits, and placement 
(subject to the following fields: Undefined, NAP, Class of Device and AM_ADDR) 
are completely arbitrary, and the example shown is not meant to limit in scope or 
spirit the invention. 

Figure 49 illustrates a second example of embedding hop count information 
in an extended INQUIRY RESPONSE message. 

In Figure 49, the hop count information has been embedded in an extended 
INQUIRY RESPONSE message. This yields a tremendous number of available bits 
(144) in which to convey hop count information. The actual number of bits can be 
much less, and the location within the extended INQUIRY RESPONSE message 
field is completely arbitrary. 

DIAC's and A-DIAC'S may be used in a two-stage procedure: First a DIAC 
INQUIRY message is sent; but, if no reply is received (i.e. no such device is 
directly reachable), an INQUIRY message with the corresponding A-DIAC is sent to 
determine if there are any indirectly reachable devices of the desired type. The 
responding Bluetooth unit then replies with an ENQUIRY RESPONSE message that 
can include the hop count to the closest device of the requested type. A hop count of 
zero would indicate that the responding Bluetooth unit is itself of the requested type. 
Note that if the hop count is included in the INQUIRY RESPONSE message, the 
two-stage procedure is not needed, since the hop count in the response (to an 
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INQUIRY message containing an A-DIAC) would indicate whether the responding 
Bluetooth unit is of the requested device type (i.e. with a hop count of 0) or whether 
it is a Bluetooth unit through which devices of the requested type are accessible. 

Additionally, there is another feature that can optionally be included in all 
embodiments of the invention. A responding Bluetooth unit that has collected the 
accessible service or device type information can then, automatically or via user 
interaction, connect (using the PAGE procedure) to one of the Bluetooth units that 
indicates that the requested service or device type is accessible. For example, this 
could be the responding Bluetooth unit that indicates the smallest hop count to a 
node offering the requested service or to a node of the requested device type, if hop 
counts are included in the INQUIRY RESPONSE message from the responding 
Bluetooth unit. If the inquiring Bluetooth unit is interested in several different 
services, or device types, it can choose to establish connections to a number of the 
responding Bluetooth units in order to get access to the whole range of requested 
services (or device types). These are just examples of the possible ways in which an 
inquiring Bluetooth unit can connect to a responding Bluetooth unit, or other 
Bluetooth unit that offers access to the desired sendee or to a Bluetooth unit of a 
certain device type. As such, these examples are no meant to limit the scope and/or 
spirit of the invention, as there are innumerable ways for an inquiring Bluetooth unit 
to connect to other Bluetooth units. 

Figure 50 illustrates, as Table 3, the different types of inquiry access codes, 
their definitions, and examples of each. 

FIG. 5 1 illustrates a block diagram of a Bluetooth arrangement in which the 
present invention can be carried out. 

The Bluetooth arrangement of figure 51 is shown as two figures. The first is 
transceiver 130, which comprises processor 134, transmitter 132, receiver 133, 
dip lexer 131 (note that element 131 could alternatively be a duplexer, switch, 
circulator, Magic T, etc., all of which allow RF energy to travel one path and not the 
other at specific times), antenna 135, waveguides 143 A and 143B, and datapath 
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144. The second shows greater detail of processor 134, which is comprised of 
memory 136, floppy drive 137, I/O buffer 138, datapath 144, microprocessor 139, 
hard drive 140, and data bus 141. The hard drive 140 and floppy drive 137 are 
optional, depending upon the unit the transceiver 130 is contained in. 

The Bluetooth operating system is a program contained in memory 136. The 
Bluetooth operating system determines how the transceiver communicates to other 
Bluetooth nodes. Microprocessor 139 executes the program steps contained within 
memory 136, in a manner that is well known in the art. Floppy drive 137 and hard 
drive 140 are optional, and may not be present in many Bluetooth arrangements, 
though, in some these components will be required. Input/Output (I/O) buffer 138 
transmits and receives data to and from the transmitter 132 and receiver 133 portions 
of the transceiver 130. It does this via data path 144. The output of the transmitter 
132 is connected to waveguide 143 A, which connects to diplexer 131, the output of 
which is connected to antenna 135. The receiver 133 is connected via a waveguide 
143B, which is also connected to diplexer 131. 

Use of a diplexer in this arrangement is well known in the art. As discussed 
previously, there are several different circuits that provide the function of a diplexer. 
The diplexer 131 allows RF energy to pass from the transmitter 132 to the antenna 
135, without harming the receiver 133 (by overloading its input circuitry). 
Similarly, the diplexer 131, allows the received RF signal to be directed to the 
receiver 133, without allowing any RF energy to leak from the transmitter to the 
receiver. 

FIG. 52 illustrates an exemplar/ set of apparatuses within which the 
arrangement of FIG. 51 can be implemented. 

In figure 52 there is shown a car stereo 541, a network access point 543, a 
refrigerator 542, a PDA 545 and a printer 544. 

Although the inventive solutions have been described in the context of 
Bluetooth technology, they are applicable to wireless ad-hoc network technologies 
in general. The concept of transferring accessibility information concerning services 
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and device types during the neighbor discovery procedure is applicable to almost 
any wireless ad-hoc network technology, although the specific details of how the 
information can be included in the response message, of course, do not apply to 
other technologies than Bluetooth. 

The embodiments described above are merely given as examples and it 
should be understood that the invention is not limited thereto. It is of course 
possible to embody the invention in specific forms other than those described 
without departing from the spirit of the invention. Further modifications and 
improvements which retain the basic underlying principles disclosed and claimed 
herein, are within the spirit and scope of this invention. 
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Clairas: 

1. In an ad-hoc network a method for providing connection information 
comprising the steps of: 

broadcasting an inquiry message, from an inquiring node, to neighboring 
nodes, the inquiry message requesting connection information about accessible 
nodes; 

receiving a response by the inquiring node from a responding neighboring 
node, the response containing connection information about the responding 
neighboring node and nodes which are accessible by the responding neighboring 
node; and 

determining whether to establish connections with the responding 
neighboring node using the connection information in the response. 

2. The method of claim 1, wherein the type of connection information 
contained in the response from the responding neighboring node depends on the type 
of inquiry message broadcast from the inquiring node. 

3. The method of claim 2, wherein the type of inquiry message is indicated 
by an inquiry access code. 

4. The method of claim 3, wherein the type of inquiry access code is an 
accessible services general inquiry access code. 

5. The method of claim 3, wherein the type of inquiry access code is an 
accessible type of device inquiry access code. 

6. The method of claim 3, wherein the type of inquiry access code is a 
dedicated accessible sendee inquiry access code. 

7. The method of claim 3, wherein the type of inquiry access code is a 
dedicated accessible type of device inquiry access code. 

8. The method of claim 3, wherein the type of inquiry access code is an 
accessibility based dedicated mquiry access code. 
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9. The method of claim 1, wherein the connection information is encoded as 
a bit map in the response. 

10. The method of claim 1, wherein the connection information is encoded 
as a list in the response. 

1 1 . The method of claim 1 , wherein the connection information in the 
response contains hop count information. 

12. The method of claim 1, wherein the response contains connection 
information in a plurality of redefined fields. 

13. The method of claim 1, wherein the response contains connection 
information in an extended response. 

14. The method of claim 1, wherein the response contains connection 
information in a plurality of redefined fields and an extended response. 

15. The method of claims 12 or 14, wherein the plurality of redefined fields 
comprises either the Undefined field, the AM_ADDR field, the NAP field or the 
Class of Device field. 

16. The mediod of claim 15, wherein the connection information contains 
hop count information in one or more redefined fields. 

17. The method of claims 13 or 14, wherein the connection information 
contains hop count information in the extended response. 

18. The method of claim 8, wherein the response contains hop count 
information. 

19. The method of claim 18, wherein the hop count information is contained 
within one or more redefined fields. 

20. The method of claim 18, wherein the hop count information is contained 
in an extended response. 

21 . The method of claim 19, wherein the redefined fields comprises either 
the Undefined field, the AM_ADDR field, the NAP field or the Class of Device 
field. 
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22. In an ad-hoc network an arrangement for providing connection 
information, the arrangement comprising: 

an inquiring node comprising: 

means for broadcasting an inquiry message, the inquiry message 
requesting connection information about accessible nodes; 
means for receiving a response; 
a neighboring node comprising: 

means for receiving the inquiry message; 
means for broadcasting the response, the response containing 
connection information about the responding neighboring node and nodes which are 
accessible by the responding neighboring node; and 

the inquiring node further comprising means for determining whether to 
establish connections with the responding neighboring node using the connection 
information in the response. 

23. The arrangement of claim 22, wherein the type of connection 
information contained in the response from the responding node depends on the type 
of inquiry message broadcast from the inquiring node. 

24. The arrangement of claim 23, wherein the type of inquiry message is 
indicated by an inquiry access code. 

25. The arrangement of claim 24 wherein the type of inquiry access code is 
an accessible services general inquiry access code. 

26. The arrangement of claim 24, wherein the type of inquiry access code is 
an accessible type of device inquiry access code. 

27 The arrangement of claim 24, wherein the type of inquiry access code is a 
dedicated accessible service inquiry access code. 

28. The method of claim 24, wherein the type of inquiry access code is a 
dedicated accessible type of device inquiry access code. 

29. The method of claim 24, wherein the type of inquiry access code is an 
accessibility based dedicated inquiry access code. 
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30. The arrangement of claim 22, wherein the connection information is 
encoded as a bit map in the response. 

31. The arrangement of claim 22, wherein the connection information is 
encoded as a list in the response. 

32. The arrangement of claim 22, wherein the connection information in the 
response contains hop count information. 

33. The arrangement of claim 22, wherein the response contains connection 
information in a plurality of redefined fields. 

34. The arrangement of claim 22, wherein the response contains connection 
information in an extended response. 

35. The arrangement of claim 22, wherein the response contains connection 
information in a plurality of redefined fields and an extended response. 

36. The arrangement of claims 33 or 35, wherein the plurality of redefined 
fields comprises either the Undefined field, the AM_ADDR field, the NAP field or 
the Class of Device field. 

37. The arrangement of claim 36, wherein the connection information 
contains hop count information in one or more redefined fields. 

38. The arrangement of claims 34 or 35, wherein the connection information 
contains hop count information in the extended response. 

39. The arrangement of claim 29, wherein the response contains hop count 
information 

40. The method of claim 39, wherein the hop count information is contained 
within one or more redefined fields. 

41 . The method of claim 39, wherein the hop count information is contained 
in an extended response. 

42. The method of claim 40, wherein the redefined fields comprises either 
the Undefined field, the AM_ADDR field, the NAP field or the Class of Device 
field. 
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